【时事五】微软、Facebook、谷歌和Twitter联合推出数据迁移项目：数据可移植性的开源计划

（来源：

1.https://opensource.googleblog.com/2018/07/introducing-data-transfer-project.html

2.https://blogs.microsoft.com/eupolicy/2018/07/20/microsoft-facebook-google-and-twitter-introduce-the-data-transfer-project-an-open-source-initiative-for-consumer-data-portability/）

【时事摘要】

         7月20日，Google和Microsoft分别在各自的博客中公布了一项名为“数据迁移”的新项目（以下简称“DTP”），这个开源项目由谷歌、Facebook、微软和Twitter联合发起，旨在帮助用户在服务提供商之间安全无缝地移动数据。这些领头企业呼吁有更多的公司可以加入进来，认为“便携性的未来需要更具包容性、灵活性和开放性”，并补充说“可移植性和互操作性是云创新和竞争的核心。”

虽然用户通常可以将其数据副本下载到本地或在线存储位置，但该项目有助于在云服务之间直接移植用户数据（使消费者能够将数据直接从一种服务转移到另一种服务，而无需下载和重新上传）。

　　这正是这些互联网巨头承诺将GDPR核心权利扩展到全球所有消费者客户的核心，并推动各自隐私设计，为用户在开源、包容、多利益相关方共同驱动的生态系统中创建工具，也将有助于服务提供商更有效地理解和实现数据可移植性。

目前，该系统通过Google、Microsoft、Twitter、Flickr、Instagram、Remember the Milk和SmugMug现有公开的API实现，可支持包括照片、邮件、联系人、日历和任务等垂直领域的用户数据传输。

作为DTP启动的一部分, 几家互联网巨头共同发布了一份白皮书^[1]，并且确定了以下几项关于互操作性和可移植性的关键开发原则，以促进用户选择，鼓励负责任的产品开发，并为用户带来最大利益。

•    为用户构建：数据可迁移工具需要开放并与行业标准互操作，易 于查找，直观易用，并且随时可供用户轻松地在不同服务之间进行数据传输或下载，为已所用。

•       使用强大的隐私和安全标准：可移植性事项的每一方服务提供商都需要具有严格的隐私和安全措施（例如在传输中加密），以防止未经授权的访问、数据分流或其他类型的欺诈。需要以清晰简洁的方式告知用户传输的数据类型和范围、数据的使用方式以及目标服务的隐私和安全实践。

•          关注用户的数据，而不是企业数据：数据可移植性需要关注单个用户具有实用性的数据，例如用户创建、导入或批准收集的数据，或者可以控制服务提供商的数据。每一企业的数据可移植性由该企业自己的内部政策控制。

•          尊重每个人：我们生活在一个人人互联、相互分享和共同协作的世界中。数据可移植性应该只关注提供与请求转移的人直接相关的数据，以便在可移植性、隐私和尝试新服务的好处之间取得适当的平衡。这意味着服务提供商需要确保所提供的私人信息中涉及的超出数据主体的人亦受到尊重。 

【M姐评论】

下图演示了用户希望将其照片从Google Dashboard移动到Microsoft OneDrive的操作流程。首先用户到Google的文件传输界面，选择目的地，然后点击“发送”，但他们必须使用授权转移。所选文件将自动复制并传送到目的地，无需使用用户的带宽或硬件。

    还有很多例子表明用户需要进行服务与服务之间的数据传输和移植，比如：

• 用户A发现新的照片打印服务提供精美创新的相册格式，但用户A的照片存储在他的社交媒体账户中。有了数据转移项目，他们可以访问照片打印服务提供的网站或应用程序，并将照片直接从他们的社交媒体平台转移到相册服务。

• 用户B不同意某音乐服务的隐私政策。他想不再使用该音乐服务，但又不想丢失用户B自己创建的播放列表。使用DTP开源软件后，用户B就可以使用原始的导出功能，音乐服务提供商将其播放列表的副本保存到云端，用户B能够导入他决定使用的新服务提供商，并在新的音乐服务或多种服务中使用他的播放列表。

• 低带宽区域的用户C一直在与室内装潢设计师讨论他的新房子设计图。在项目结束时，用户C希望从共享存储系统转移所有文件到用户C自己的云存储服务器。用户C可以在没有足够带宽资源的情况下，通过云存储数据迁移项目用户界面（UI）移动数百个大文件直接到自己的云存储服务器。

• 超市行业协会希望各连锁超市各分店允许顾客转移他们的购买历史记录，这样用户可以根据他们在连锁超市的购买习惯获得优惠券。该协会将安装一个行业特定主机平台来实现DTP。

对此时事和上述场景的解读，M姐首次尝试从技术角度进行剖析，以让读者对DTP如何落地可移植性产生较直观的认知。

DTP是将数据可移植性扩展到了下载数据副本以外的能力^[2]，通过开源代码的方式，让用户实现在两个平台间更加容易、便捷的数据迁移功能，并且不会增加两个在线服务提供商的基础设施负担^[3]，反而还提供了便携性的服务数量，创造利益跨越更广泛的生态系统：对用户有益（在用户控制下，传输数据更为方便、省事，还能促进用户对感兴趣的各类服务中个人数据的重用^[4]），对企业有利（促进组织之间用户对个人数据的受控和有限共享，从而丰富服务和客户体验，下文将具体展开），对整个生态也产生积极效果（允许用户选择产品和服务而不是被“锁定”，有助于推动产品创新和促进竞争^[5]）。

        DTP是如何实现数据在平台间无缝移植呢？

以前，由于缺乏统一的Data Model，如果用户想把新浪博客中的内容搬迁到其他博客中，新浪需要提供对主流博客服务平台的搬家工具，每个搬家工具需要去实现不同的认证模块，调用数据读取API和进行数据转换，然后再使用自己的写操作API导入数据到自己的后台。

　　按这种传统的模式，由于每个服务提供商都可以拥有自己的数据模型，因此从一个服务提供商将数据传输给另一个服务提供商，就需要开发一套适合两两平台间可以互相识别的数据格式，并且还需要创建支持相同适配器数据模型的数量。以下面左图为例，需要维护的垂直领域数据格式有=21，即总共21种数据格式。

                现在，如上面右图，通过DTP，所有自愿进行合作的服务商之间只需要建立一个通用的垂直领域数据模型（Data Models）即可。数据模型通常通过行业分组聚集在一起，形成垂直领域，如照片、电子邮件、联系人或音乐。服务提供商可能有一个或多个垂直数据领域，每一种垂直领域都有自己的特定格式即数据模型。例如，Music Vertical可以包含音乐、播放列表和视频，照片Vertical包括标题、描述、专辑等信息）^[6]。

      然后各服务提供商就可以使用数据适配器将自己的数据格式与一段通用代码（即数据模型）进行转换。一般情况下数据适配器成对出现：提供数据的服务商通过其数据适配器将数据经过API接口导入数据模型，将格式转换后再通过接受数据服务提供商的API和其适配器转换化成自己的数据格式。当然，适配器还有另外一种，叫身份验证适配器，它是用户将数据传输给另一个服务提供商前对其身份进行验证的代码段。

      此外，DTP系统还有一个组成部分，叫任务管理库，它提供管道为系统供电、处理后台任务，例如相关适配器之间的调用、安全数据存储、重试逻辑、速率限制、分页管理、故障处理和个人通知。

   通过DTP的三大组成部分，每个服务提供商只需要建立和维护API，尽可能支持现有标准（如OAuth和REST）和某垂直领域的数据格式与数据模型的转换即可，便可参与DTP生态系统中任何两个服务提供商之间的直接数据传输，大大减少了工作量与维护成本。由于参与是自我决定的因，DTP就是相互协作的持续且有共益性的共享承诺。

　　还是以新浪博客搬家为例，有了Data Model，新浪只需要实现自己的数据到Data Model的转换，提供自己的授权Adaptor即可，便可实现与所有博客提供方（前提是对方也加入DTP）的互操作（比如搬家操作）。

      上图就比较好地诠释了M姐用大段文字说明的可移植机理。服务提供商A、B、C 分别是服务于邮件和照片的垂直领域，他们可以先通过身份适配器验证请求数据迁移的用户身份，然后通过数据适配器，将自己的数据格式与通用数据模型进行转换，最后再分别由服务提供方D、E、F自己的数据适配器转化后读取数据并通过API接口写入各自的服务器中。

  数据可移植性如何保证用户数据的完整性、保密性和可用性？

       被请求数据迁移的控制者，为了符合数据可移植性权利，首先必须告知数据主体可移植权的存在。其次，当要求数据控制者应答数据可移植性请求时，数据控制者不能保持缄默^[7]，根据GDPR第12条第3款的规定，数据控制者应当自收到请求起不超过一个月的期限内进行操作。对于复杂情况而言，期限最长可延长至三个月，前提是数据主体在请求发出后的一个月内被告知延迟的原因^[8]。并且，根据GDPR第20条规定，数据控制者应答数据可移植性请求，是代表数据主体行事，应设置适当的保障措施。例如，在传输之前或最初要求用户给予处理的“同意”或者在确定合同之前获得数据主体的“确认”，以确保传输的数据类型确实是数据主体想要传输的；将个人数据安全地传输（通过端到端数据加密）到正确的目的地（如使用强认证措施）；还要继续保护系统中剩余的个人数据--当处理包含多个数据主体的个人数据时，不应出于任何目的对第三方的权利和自由产生不利影响；以及处理可能发生的数据泄露的透明性程序^[9]。因此，数据控制者应评估与数据可移植性相关的特定风险，并采取适当的风险缓解措施。并且，数据控制者不得以泄露商业秘密或知识产权信息传输数据主体提供的个人数据。再次，进行可移植性操作的数据控制者应确保传输的数据是准确、完整并且最新的^[10]。如果所请求的个人数据是由数据处理者处理的，则其需要根据GDPR第28条签订的合同通过适当的技术和组织措施协助“控制者”，（......）响应行使数据主体权利的请求。

          接收数据的控制者负责确保接受和保留的数据只是自己提供服务所必需和相关的数据。首先，与权利主体请求目的无关的信息不应被保留和处理，更没有理由接受和处理在数据可移植性请求之后传输的个人数据。其次，与权利主体请求目的相关的信息，即使被接收数据控制者保存，应当由提起请求的用户单独控制，接收方数据控制者（可以根据用户的请求向其发送数据）不应将所传输的第三方数据用于自己的目的，在未经用户知情同意的情况下，不应使用此信息来构建第三方数据主体的画像并丰富其社交环境，也不应用于检索该第三方信息并创建特定的配置文件。否则，这种处理可能是非法和不公平的，特别是在第三方权利主体没有被告知并且不能行使其作为数据主体的权利的情形下。再次，在可行的情况下，接收方数据控制者应该为所涉及的其他数据主体实施同意机制，以便在该类主体授权下简化数据传输方式。

      综上，接收方应当适用GDPR第5条规定的原则，如合法性、公平性和透明度、目的限制、数据最小化、准确性、完整性和机密性、存储限制和问责制。

数据可移植性如何保证用户的隐私与安全，并使任何透明度不受损失？

首先，服务提供者可以使用仪表板（即Dashboard，如第一幅图中Google Dashboard为例）以摘要形式提供数据，并使用“简洁、透明、易懂和易获取的形式以及清晰平实的语言”提供相关概述^[11]，以致数据主体可以清晰地知道，根据既定的目的，他要下载哪些数据，以及将数据如何传输到另一个数据控制者。比如，数据主体可以使用应用软件轻松地识别、认定和处理来自于他的特定数据。并且服务提供商不得通过征收额外费用的形式妨碍用户行使该等权利。

其次，任何两个服务提供者之间的数据迁移通过现有授权机制，允许每个服务提供商对各自的服务安全进行控制。 如下图所示，这是DTP系统组件之间的交互展示。左端的网关服务器（Gateway Sever）通过身份验证适配器对导出和导入数据的用户身份进行验证。右端的Worker类似一个被隔离的虚拟机，它可以启用数据适配器进行数据传输并且协调与执行数据进出的任务，它在创建时会生成一个临时密钥但在传输完成后密钥被销毁。迁移过程中所需的加密证书和元数据一般会在数据管理库（Blob Store）中临时性存储。

这样设计的好处在于无论是在数据传输或者储存的过程中，托管主体^[12]的管理员因无法接触到临时密钥因此也接触不了用户的数据，因此保证了数据在传输层的安全迁移。并且，不但任何服务提供商可以选择向哪个适当的托管主体开放API接口，托管主体也可以根据服务提供商实施隐私实践及对用户数据保护的情况来选择是否从该服务提供商请求API接口。这样，将会构建一个确保数据迁移安全的生态（包括服务提供方、托管主体、对DTP提供代码/工具和建议的贡献者和用户）。

最后，用户数据的安全性和隐私性应被理解是数据迁移项目的最基本原则。比如，在提供商之间传输数据时，应实施数据最小化。这意味着接收方数据控制者为用户提供服务时应只处理和保留最小数据集；托管实体应配置其主机平台^[13]以通知用户数据迁移已经被发起并向用户发送迁移请求的提醒通知；服务提供商应允许用户提出其数据被成功转移后予以删除^[14]的要求；服务提供商和托管实体应该确切地评估数据敏感性以及对已知和可能的攻击进行适当地速率限制；所有数据在系统传输或者存储过程中都是加密的。在任何情况下，数据控制者必须实施认证程序，以便事先识别并确定请求其个人数据的数据主体身份。包括：使用数据主体的身份验证信息（如共享密钥）或其他身份验证因素（如一次性密码）对其进行身份验证; 如果怀疑账户遭到入侵，则暂停或冻结传输; 在从数据控制者直接传输到另一个数据控制者的情况下，应该使用授权的认证，例如基于令牌的认证。^[15]

　　通过技术加法律角度疱丁解牛似地层层分析，M姐深感几大国际互联网巨头们所公布的DTP开源计划，已经符合了GDPR以及W29指引下的相关要求。M姐建议我国各大互联网公司，也可以参与到此项目中，技术大牛们也可以积极尝试将自己的insight贡献到开源文档库：https://github.com/google/data-transfer-project，共同致力于数据可移植的安全生态建构。

---

引用：

[1] 白皮书内容可查阅: file:///E:/Data%20Protection/个人信息安全/GDPR/Rules/Data%20Portable%20right/data-transfer-project-google-whitepaper-v4.pdf

[2] 这正体现了GDPR第20条第（1）款中的数据可携带的定义：“数据主体有权以结构化，常用和机器可读的格式接收他或她提供给控制器的有关他或她的个人数据，并有权将这些数据传输给另一个控制器而无需来自提供数据的控制器的障碍。”

[3] 第20（2）条还规定了数据控制者的义务，以便“在技术上可行时”将便携式数据直接传输给其他数据控制者。技术可行性应根据具体情况进行评估，它不应使控制者有义务采用或维护技术上兼容的处理系统，但数据控制者以可互操作的格式传输个人数据（引自第29条工作组在《数据可携带权指南》（16 EN WP 242 rev.01）第17页）。

[4] 引自第29条工作组在《数据可携带权指南》（16 EN WP 242 rev.01）第5页。

[5] 第29条工作组在《数据可携带权指南》（16 EN WP 242 rev.01）第3页Executive Summary中指出，“数据可移植性是支持欧盟个人数据自由流动和促进控制者之间竞争的重要工具。它将促进不同服务提供商之间的转换，从而促进在数字单一市场战略背景下开发新服务。”

[6] 第29条工作组在《数据可携带权指南》（16 EN WP 242 rev.01）第3页Executive Summary中指出，数据可移植请求的方法应保证个人数据以结构化、常用和机器可读的格式传输，并应鼓励它们确保在执行数据可移植性请求时提供数据格式的互操作性。

[7] 引自第29条工作组在《数据可携带权指南》（16 EN WP 242 rev.01）第15页。

[8] 引自第29条工作组在《数据可携带权指南》（16 EN WP 242 rev.01）第14页。

[9] 符合关于“全联盟网络与信息系统高度共同安全保障措施”的2016/1148号指令（EU）。

[10] 引自第29条工作组在《数据可携带权指南》（16 EN WP 242 rev.01）第6页和第13页。

[11] 引自GDPR第12条第1款。

[12] Hosting Entity：A Hosting Entity is the entity that runs a Host Platform of theDTP.In most cases it will be the Provider sending or receiving the data,but could be a trusted third-party that wants to enable data transferamong a specific group of organizations. （引自DTP白皮书，网址：file:///E:/Data%20Protection/个人信息安全/GDPR/Rules/Data%20Portable%20right/data-transfer-project-google-whitepaper-v4.pdf）

[13] Host Platform：A Host Platform is the technical environment where a DTP instancecan be hosted. This can be a cloud environment, enter prise infrastructure, or a localserver.  As of July 2018, the supported cloudhost platforms include GoogleCloud Platform and Microsoft Azure. （引自DTP白皮书，网址同上。）

[14] 只要数据控制者仍在处理数据，数据可移植性便不会自动触发数据从数据控制者的系统中删除，也不会影响已发送数据的原始保留期。但是，如果数据主体要求行使其删除权（如第17条规定的“被遗忘权”）的，数据控制者不得对数据可移植性后的数据作延迟或拒绝删除的处理。

[15] 引自第29条工作组在《数据可携带权指南》（16 EN WP 242 rev.01）第19页。